FIG. 1 illustrates a Bluetooth piconet 1. This is an ad-hoc radio communications network controlled by a Master device 2, and including the Master device 2 and up to seven Slave devices 4, 6, 8, 10. The devices of the piconet 1 are synchronised to a common time reference 20 as illustrated in FIG. 2. The common time reference is synchronised to the Bluetooth clock of the Master device 2.
As illustrated in FIG. 2, communications in the piconet 1 occur as a sequence of packet data units (PDU) 22. The PDUs 22 are communicated in a time division duplex (TDD) fashion. The common time reference 20 is divided into a series of TDD frames 30. Each TDD frame comprises two time slots. The first time slot 31 of a TDD frame is allocated to the Master 2 of the piconet 1. Only the Master 2 can begin transmission of a PDU in the first slot 31 of a TDD frame 30. The second slot 32 of a TDD frame 30 is allocated to a single Slave in the piconet 1. Only that allocated Slave can begin transmitting a PDU 22 in the second time slot 32 of the TDD frame 30. Only the Slave addressed in the first time slot 31 of a TDD frame 30 can reply in the second time slot 32 of that TDD frame 30.
A PDU 22 comprises a header and a payload. An access code of the header identifies the Master of the piconet and an address within the header identifies the device addressed. The access code within the header is also used for maintaining synchronisation to the common time reference 20 at each of the devices within the piconet 1. Accurate time synchronisation is necessary as the piconet 1, according to the Bluetooth standard, uses fast frequency hopping and it is imperative that the Master and Slaves hop together.
Referring to FIG. 2, the Master 2 at slot 31A sends a PDU to the Slave S1. This enables the Slave S1 to reply with a PDU sent to the Master 2 in slot 32A. The Master 2 sends a second PDU 22 in time slot 31B which also enables the Slave S1 in time slot 32 to reply. However, the Slave S1 is not obliged to reply. In time slot 31C, the Master 2 sends a PDU 22 to the Slave S3, which replies with a PDU 22 in a time slot 32. In time slot 31D, the Master 2 sends a PDU 22 to the Slave S2, which replies in the immediately following time slot 32D with a PDU 22.
It will therefore be appreciated that a single communication channel exists within the piconet 1. This communication channel operates in a TDD fashion and includes a downlink channel from the Master 2 in a first slot 31 of a TDD frame 30 and an uplink channel to the Master in the second slot 32 of that TDD frame 30. The communication channel may be allocated to a particular Slave by having the Master poll that Slave, by sending a PDU addressed to it, in the first time slot of a TDD frame 30.
In order to maintain synchronisation within the piconet 1, the Bluetooth Master device 2 typically polls a Slave at least every 25 ms. Consequently, by default, the communications channel will be allocated to a Slave at least once every 25 ms.
FIG. 3 illustrates an example of an asynchronous data transfer protocol. In this example the asynchronous data transfer protocol is the OBEX (Object Exchange) protocol. This is a compact binary protocol originally developed by the Infrared Device Association (IrDA) for infrared communication that can be used with other transport mechanisms, such as Bluetooth. OBEX performs a function similar to HTTP but is less resource intensive. The OBEX protocol is a session-orientated protocol, in that a session is initiated for data transfer and is then terminated when data transfer is complete. During a session, an OBEX client 40 pushes a data block using the PUT command to a server 42. The server 42 acknowledges receipt of the data block contained within the PUT command by sending a CONTINUE response to the client 40. The client 40, after receiving the CONTINUE response for the previous data block transfer, proceeds with the next data block transfer by sending another PUT command 50 to the server 42, which will acknowledge receipt by returning a CONTINUE response 52. Because of the asynchronous nature of the data transfer protocol, there may be a delay at the server between the receipt of a PUT command 50 and the transmission of a CONTINUE response 52. Likewise, there may be a delay at the client 40 between the receipt of a CONTINUE response 52 and the transmission of the next PUT command 50.
The OBEX protocol may be used to transfer data using Bluetooth PDUs as the transport mechanism. However, the latency between the receipt of a PUT command and the production of a CONTINUE response at the server 42 may be greater than a TDD frame duration (1.25 ms). Likewise, the latency at the client 40 between the receipt of a CONTINUE response 52 and the production of the next PUT command 50 may be greater than a TDD frame duration (1.25 ms).
Consequently, if the Master device 2 is operating as the client 40, and it sends a PUT command 50 to a server 42 acting as a Slave in a first slot 31 of a TDD frame 30, the server 42 is unlikely to be able to reply with a CONTINUE response 52 in the second slot 32 of that TDD frame 30. Consequently, the OBEX server 42 acting as the Slave device, will have to wait until it is next polled by the Master before it can send the CONTINUE response 52 back to the OBEX client 40. This will typically be a delay of 25 ms.
If the Master 2 is operating as the OBEX server 42, it is unlikely that the OBEX client 40, acting as the Slave, will be able to respond to a received CONTINUE response 52 sent in the first slot 31 of a TDD frame 30 by sending a PUT command 50 in the immediately following second time slot 32 of that TDD frame 30. Consequently, the OBEX client 40, operating as a Slave device, will have to wait until it is polled by the Master device 2 before it can provide the next PUT command 50 to the OBEX server 42.
It is therefore apparent that significant delays can occur if large amounts of data need to be transmitted using an asynchronous data transfer protocol between a Master device and a Slave device, in particular, where the Master device grants the Slave device access to a communication channel on a transaction by transaction basis.